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AMENDMENTS TO TF TF. n.ATMS: 

1 . (Currently amended) A method for recording and replaying execution of distributed 
programs on a computer system in a distributed environment, comprising: 

identifying an execution order of critical events of a program; 

generating groups of critical events of said program, wherein for each group, critical 
events belonging to said group belong to a common execution thread; and 

generating, for each execution thread, a logical thread schedule that identifies a sequence 
of said groups so as to allow deterministically replaying a non-deterministic arrival of stream 
socket connection requests, a non-deterministic number of bytes received during message reads, 
a non-deterministic binding of stream sockets to local ports, and a non-deterministic arrival of 
datagram messages^ 

wherein said d R t^-rministicallv replaying comprise s recording events of a plurality of 
virtual machinRs. each v irtual mar.h ine being a.ssigned a unique virtual m achine id e n tity during a 
record phase . 

2. (Origmal) The method according to claim 1 , wherein a virtual machine m said distributed 
environment is modified to record events. 

3. (Original) The method according to claim 2, wherein virtual machines in said distributed 
environment communicate with one another and events are recorded on each virtual machine. 

4. (Original) The method according to claim 1, fijrther comprising: 

recording an arrival order of a message to guarantee the order and replay of applications. 

5. (Original) The method according to claim 1 , wherein said deterministically replaying 
includes: 

modifying an implementation of a virtiial machine of said distributed environment to 
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record information on what transactions are occurring at an appUcation level and using said 
information to replicate a same behavior in a replay. 

6. (Original) The method according to claim 5, wherein an implementation of said virtual 
machine of said distributed environment is modified without changing an appUcation being run. 

7. (Currently amended) The method according to claim 1 , wherein said dcluiiuniAtically 
iLpla^uig includes : recording events of said a plurality of virtual machines has having 
applications on each machine and m J»vtng threads of a same appUcation program running, said 
recording of said events providing a deterministic replay of events. 

8. (Original) The method according to claim 1, wherein each of a plurality of virtual 
machines in said distributed environment records events at each said machine, and each said 
virtual machine communicates with one another, to guarantee the same execution order for the 
replay of any shared applications on said each virtual machine. 

9. (Previously presented) The method according to claim 1 , wherein said program includes 
critical and non-critical events, and wherein said method further includes: 

recording said critical events and logging a value of a global counter and a local counter, 
a smgle said global counter residing on a virtual machine, and said local counter residing on each 
thread of a virtual machine associated with said critical event. 

10. (Original) The method accordmg to claim 1 , wherein said replay is based on logical 
thread schedules and logical intervals. 

1 1 . (Original) The method according to claim 1 , wherein said replay is for a non- 
deterministic arrival of point-to-point stream socket connection requests. 



PAGE 5«8 • RCVD AT 5/28/2004 2:21:33 PM [Eastern Daylight Time] • SVR:U8PT0.EFXRF-i;4 * DNI8:8729306 • C8ID:703781237S • DURATION (mm-ss):11-10 



05/28/2004 14:17 FAX 7037612375 



McGinn&Gibb . PLLQ 



11006/028 



Serial No. 09/520,008 4 
Docket No. YOR919990502US1 

12. (Original) The method according to claim 1 , wiierein said replay is for a non- 
deterministic number of bytes received during point-to-point stream socket mess^e reads. 

13. (Original) The method according to claim 1 , wherein said replay is for a non- 
deterministic binding of stream sockets to local ports. 

14. (Original) The method according to claim 1, wherein said replay is for a point-to-point 
datagram User Datagram Protocol (UDP) message sent to a single receiver. 

1 5 . (Original) The method according to claim 1 , wherein said replay is for a point-to-points 
datagram User Datagram Protocol (UDP) message sent to multiple receivers. 

1 6. (Original) The method according to claim 1 , -wherein said replay is for a non- 
detemiinistic arrival of number of bytes of point-to-point stream socket data. 

1 7. (Original) The method according to claim 5, wherein said modified virtual machine is 
operable in a record mode such that logical thread schedule information and network interaction 
information of the execution are recorded while an application program runs, and in a replay 
mode, such that the execution behavior of the program is reproduced by enforcing the recorded 
logical thread schedule and the networic interaction. 

1 8. (Original) The method according to claim 1 , wherein replaying of a multithreaded 
program includes: 

capturing a logical thread schedule information duruig one execution of the program; and 
enforcing an exact same schedule when replaying the execution. 

1 9. (Original) The method according to claim 1 8, wherein said logical thread schedule 
comprises all of a plurality of physical thread schedules in an equivalence class. 
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20. (Original) The method according to claim 1 , wherein each of said critical events represent 
one of a shared- variable access and a synchronization operation, said critical events affecting 
logical thread schedules, 

said synchronization operation comprising one of a synchronized block and wait 
synchronization operation, a monitorenter synchronization operation, and a monitorexit 
synchronization operation, 

wherein a different thread enters the critical section only after a first thread has executed 
the monitorexit operation. 

21 . (Original) The method according to claim 20, wherein said critical events further include 
wait, notify,and notify All synchronization operations for coordinating the execution order of 
multiple threads, and an interrupt synchronization operation that interrupts the execution of a 
thread at any point. 

22. (Original) The method according to claim 1 , wherein critical events comprise events 
whose execution order affect the execution behavior of the application, 

wherein a logical thread schedule comprises a sequence of intervals of critical events, and 
wherein each interval corresponds to the critical and non-critical events executing 
consecutively in a specific thread. 

23 . (Original) The method according to claim 1 , wherein for each given group of critical 
events, said critical events of the interval are consecutive, and only non-critical events can occur 
between consecutive critical events in the interval, and wherein said groups are ordered and no 
two adjacent intervals belong to the same thread. 

24. (Original) The method according to claim 1, wherein only a critical event interval 
comprising a first critical event and a last critical event is traced and recorded. 
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25 . (Currently amended) The method according to claim 1 8, wherein critical events 
belonging to a given group are represented by an ordered pair of < FirstCriticalEventp] , 
LastCriticalEventfiJ >, and 

wherein FirstCriticalEventfiJ identifies the first critical event in the interval / and 
LastCriticalEventfiJ identifies the last critical event in the interval i. 

26. (Previously presented) The method according to claim 1 , wherein a logical schedule 
interval LSIfiJ corresponding to an interval/ when the specific thread is scheduled for execution 
identifies the critical events that occur in the interval i. 

27. (Original) The metiiod according to claim 24, wherein a value of FirstCriticalEventfiJ 
and LastCriticalEventfiJ represent a global clock value that indicates the time that a 
corresponding event was executed, and is recorded, wherein such global clock values identify the 
ordering of events in an execution stream. 

28. (Original) The method according to claim 1, wherein each said critical event is identified 
by a global counter value that reflects an execution order of said critical events. 

29. (Currently amended) The method according to claim 1, wherein capturing logical thread 
schedule information is based on a global counter shared by all the threads and one local counter 
exclusively accessed by each thread, 

wherein the global counter increments at each execution of a critical event to uniquely 
identify each critical event, and wherein a FirstCEventi and a LastCEventi are represented by 
their corresponding global counter values, and 

wherein the globed counter is global within a particvdar virtual machine and each said 
virtual machine includes a different global covmter, and a local counter increments at each 
execution of a critical event, such that a difference between the global counter and a thread's 
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local counter is used to identify dynamicaUy the logical schedule interval. 

( 
( 

30. (Original) The method according to claim 1 , wherein each critical event is uniquely 
associated with a global counter value, and wherein global counter values determine the order of 
critical events. 

31 . (Original) The method according to claim 30, wherein updating the global counter for a 
critical event and executing the critical event, are performed in one atomic operation for shared- 
variable accesses. 

32. (Origmal) The method according to claim 1 , wherein updating the global counter and 
executing the event both in one single atomic operation is only performed durijig the record 
phase. 

33. (Currently amended) The method accordmg to claim 1 , wherein for a thread to execute a 
schedule interval LSI i = <FirstCEventi ; LastCEventi>, during the replay phase, the thread 
waits until the global counter value becomes the same as FirstCEventi without executmg any 
critical events, and when the global counter value equals FirstCEventi, the thread executes each 
critical event and also increments the global counter value untU the value becomes the same as 
LasiCEventi, and 

wherein when the global counter value equals LastCEventi, the thread fetches its next 
schedule interval, LSI i+1 = <FirstCEventi+ 1 ; LastCEventi+I >, from the log and waits until 
the global counter value becomes the same as FirstCEventi+I, an operation being repeated until 
no more schedule intervals exist in the log. 

34. (Currently amended) The method according to claim 1, wherem for point-to-point 
communication, a socket is created, and getlnputStreamO and getOutputStreamO of the Socket 
object return hiputStream and OutputStream objects to be used for reading via a readQ method 
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call and writing via a >vrffe(? method call stream data over the socket stream, 

wherein a plurality of socket appUcation programming interfaces (APIs) are provided 

including socket APIs for listening for connections on a stream socket via a listenQ method call, 

bmding a socket to a local port via a bindQ method caU, and determining the ntimber of bytes 

that can be read without blocking via an availableQ method call, arid 

wherein each stream socket caU including acceptQ, bind. createQ, listenQ. connectQ. 

closeO. availableQ. readQ. and writeQ is mapped mto a native method call in a virtual machine 

implementation. 

35. (Original) The method according to claim 1, wherein deterministic replay of network 
events comprises deterministic re-establishment of socket connections among , threads. 

36. (Currently amended) The method according to claim 7, wherein said eadi vhlualmadune 
is assigned a unique virtual machine identity (VM-t^ is dmiiig a i c cuid phase. 

iiaiaiduitity being logged in the record phase and reused in a replay phase, to aUow 
identification of a sender of a message or connection request. 

37. (Currently amended) The method according to claim 1, wherein critical events on a 
virtual machine are identified by tiieir global counter value on the virtual machine, and a 
networkEventId is used to uniquely identify a network event in a distiibuted application, and 

wherein said networkEventId is defined as a tuple <threadNum. eventNwri>, where 
threadNum is a thread number of a specific thread executing the network event and eventNum is 
a number that identifies the network event within the thread, said eventNum being used to order 
network events within a specific thread. 

3 8 . (Original) The method according to claim 37, wherein a connectionid is for identifying a 
connection request at a connect network event, 

said connectionid is a tiiple, <dJVMId threadNum>. where dJVMd is the identity of the 
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virtual machine at which the connect event is being generated, and threadNum is the thread 
number of the client thread generating the connection request. 

39. (Previously presented) The method according to claim 38, wherein said threadNum has a 
same value in both the record and replay phases, and wherein events are sequentially ordered 
within a thread, and the eventNum of a particular network event executed by a particular thread is 
guaranteed to be the same in the record and replay phases. 

40. (Previously presented) The method according to claim 1 , wherein a network operation is 
marked as a critical event, thereby allowing threads performing operations on different sockets to 
proceed in parallel. 

41. (Currently amended) The method according to clmm 39, wherein, in the record phase, at 
the connect, a virtual machine-client sends a socket-connection request to a server, 

when the socket connection is estabUshed, the client thread on the virtual machine-cUent 
sends the connectionid for the connect over the established socket as the first data,. 

42. (Original) The method according to claim 39, wherein, in the replay phase, the virtual 
machine-client executes the connect and sends the connectionid of the connect to the server as 
the first data, said connect being a critical event, such that the virtual machine-client ensures that 
the connect call returns only when the globalCounter for this critical event is reached. 

43. (Currently amended) The method according to claim 42, wherein, on the server side, 
during the record phase, at an accept, a virtual machine-server accepts the connection and 
receives the connectionid sent by the client as the first data at the corresponding connect, the 
virtual machine-server logging information about the connection established into the 

NetworkLogFile, and 

wherein for each successful accept call, the log contains a ServerSocketEntry, said 
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ServerSocketEntry comprising a tuple, <serverld . clientid >. wherein said serverld is the 
networkEventJd of the correspondingaccepr event and wherein said clientid is the comectionid 
sent by the virtual machine-client 

44. (Previously presented) The method according to claim 1 , wherein during a record phase 
having a client that performs a connect and a server that performs an accept, a method 
comprising: 

on the client side, performing a recording of critical events including 
enterGCCriticalSection, updating ClientGC, and leaveGCCriticalSection; 
sending a coimection request to the server side; 

on the client side, sending a ClientEventID as a tuple comprising <clientJVMId. 
ClientGC> to the server; 

on the server side, receiving the ClientEventID and logging, by the server side, 
<ServerGC, ClientEventID> into a ServerSocketLog. 

45. (Previously presented) The method according to claim 44, wherein, for replaying accept 
events, a virtual machine includes a connection pool for buffering out-of-order connections, 

wherein during the replay phase, when an accept is executed by a server threadr_5:on the 
virtual machine-server, said virtual machine-server identifies a networkEventId for the accept 
event, and 

wherein a connectionid is identified bom a. NetworkLogFile with matching 
networkEventId value, and said virtual machine-server checks the connection pool to determine 
whether a Socket object has been created with a matching connectionid. 

46. (Previously presented) The method according to claim 45, wherein if the Socket object 
has been created, the Socket object is returned by said virtual machine-server to complete the 
accept, and 

wherein if the Socket object has not already been created with a the matching 
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cormectionld, the virtual machine-server buffers information about out-of-order connections in 
the connection pool until said virtual machine-server receives a connection request with the 
matching connectionid, said virtual machine-server then creating and returning a Socket object 
for the matching cormection. 

47. (Previously presented) The method according to claim 45, wherein an accept on the 
server side during the replay mode includes: 

recording critical events; 

retrievmg a ClientEventID which equals a recValue from the ServerSocketLog for a 

respective ServerGC; 

checkmg the connection pool for the recValue, wherein if the recValue is in the 
connection pool, then the process ends, and 

wherein if the recValue is not in the coimection pool, then the method further comprises: 
accepting a coimection request and receiving the ClientEventId by the server; and 
determining whether the ClientEventId is not equal to the recValue, and if not 
equal, then saving the ClientEventId in the connection pool, and if it is determined that 
theClientEventld is equal to the recValue, then the process ends. 

48. (Previously presented) The method according to claim 47, wherein socket read and write 
events are identified as critical events in a virtual machine, and the virtual machine's global 
coimter is updated for each of these calls, 

wherein in the record phase, the virtual machine executes the read and logs a thread- 
specific eventNum and number of bytes read numRecorded in a NetworkLogFile, 

49. (Previously presented) The method according to claim 48, wherein in the replay phase, at 
a corresponding read event, the virtual machiae reads only the numRecorded number of bytes 
even if more bytes are available to read. 
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50. (Previovisly presented) The method according to claim 48, wherein in the replay phase, at 
the corresponding read event, the virtual machine thread retrieves the numRecorded number of 
bytes from a NetworkLogFile corresponding to a current eventNum and the thread reads only the 
numRecorded bytes even if more bytes are available to read, or will block until numRecorded 
bytes are available to read, and 

wherein the execution returns ftom the read call only when the globalCounter for the 

critical event is reached. 

5 1 . (Original) The method according to claim 50, wherein during a record mode, for a readQ 
method call, the read event is executed, returning "n" bytes read which is logged in a 
recordedValue, and the critical event correspondmg to the read is logged. 

52. (Currently amended) The method according to claim 50, wherein during a replay mode 
for a readQ method call, the read critical event is executed returning the number n of bytes read, 

wherein if n is greater than the recorded value, the read critical event is executed again, 
and wherein if n is less than the recorded value, the read critical event is executed again and bytes 
are read until the recordedValue number of bytes are read, and 

wherein when n is equal to recordedValue, then the read critical event is recorded by 
performing a enterGcCriticalSection and leaveGcCriticalSection, and the process stops. 

53 . (Previously presented) The method according to claim 52, wherein for multiple writes on 
a same socket, replaying of the writes to the same socket occur in a same order and all reads 
from the socket read the bytes in a same order in both record and replay modes. 

54. (Currently amended) The method according to claim 53, wherein an occurrence of 
multiple writes to a same socket are recorded, without recording other events that do not operate 
on the same socket, and 

wherein said events that do use the same socket are blocked by using a lock variable for 
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each socket. 

55. (Previously presented) The melhod according to claim 54, wherein an 
enterFDCriticalSection(socket) allows only reads or writes coiresponding to that socket to 
execute the code therein, thereby preserves an execution ordering of different critical events. 

56. (Original) The method according to claun 53, wherein available and bind call events 
comprise critical events, and implement a network query, 

wherein said available call checks a number of bytes available on the stream socket, and 
s^d bind call returns a local port to which the socket is bound, 

wherem said available call comprises a blocking call, and in the record phase, is executed 
before enter a GC-critical section, and the virtual machine records a number of bytes available, 

wherein in the replay, phase, the available call event blocks until it returns the recorded 
nxmiber of bytes available on the stream socket, 

wherein said bind event, in the record phase, is executed within the GC-critical section 
and the virtual machine records its return value. 

57. (Original) The method according to claim 1, wherem user datagram protocol sockets are 
created via a DatagramSocket class, and 

wherein during a record phase, a sender virtual machine intercepts a datagram sent by an 
q)pUcation and inserts a DGNETEventId of a send event at an end of a data segment of the 
application datagram, and the virtual machine increases a length field of the datagram to include 
an added size for a datagram identification. 

58. (Original) The method according to claim 57, wherein if the datagram is larger than a 
predetermined size, said datagram is split, with each split datagrams carrying the same 
DGNETEventId, and different tags including one of FRONT_UDP and REAR_UDP, to indicate 
one of a itoxA portion or rear portion. 
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59. (Original) The method according to claim 58, wherein if said datagram is less than or 
equal to the predetermined size, then the datagram carries information that it is a whole 
datagram. 

60. (Original) A method for supportbg execution replay with respect to a stream socket 
Application programming interface (API) comprising: 

identifying an execution order of critical events of a program; 

generating groiq)s of critical events of said program, wherein for each group, critical 
events belonging to said group belong to a common execution thread; and 

deterministically replaying non-deterministic arrival of stream socket connection 
requests, non-deterministic number of bytes received during message reads, and non- 
deterministic binding of stream sockets to local ports^ 

wherein said deterministicaUv replaying compri ses recording events of a plurality of 
virtual machines, each virtual machine being assigned a u n ique virtual machine identity during a 
record phase .. 

6 1 . (Previously presented) A method for supporting execution replay with respect to 
datagram socket Application Programming Interface (API) including: 

identifying an execution order of critical events of a program; 
generating groups of critical events of said program, wherein for each group, critical 
events belonging to said group belong to a conomon execution thread; 
determining out-of-order delivery of packets; and 

determining a non-deterministic number of packets delivered during different executions 
of the same program, for supporting an execution replay with respect to said datagram socket 
Application Programming Interface (API)^ 

wherein said execution renlav comprises recording events of a plurality o f virtual 
machines, each virtual machine being assigned a unique virtual machine identity during a record 



PAGE 16/28 ■ RCVD AT 5/28/2004 2:21:33 PM [Eastern Dayligm Time] ■ SVR:U8PTO.EFXRF-1/4 * DNI8:872930B * C8ID:7037612375 ' DURATI N (mm-ss):11-10 



05/28/2004 14:21 FAI 7037612375 



McGinn&Gibb.PLLC 



121017/028 



Serial No. 09/520,008 15 
Docket No. YOR919990502US1 

phase .. 

62. (Original) The method according to claim 6 1 , wherein packets are sent to multiple 
receivers. 

63 . (Original) The method according to claim 62, wherein said replaying allows repeating the 
exact behavior of thread execution and events in a distributed environment. 

64. (Currently amended) A software facility system for allowing recording and replaying 
execution of distributed programs on a computer system m a distributed environment, 
comprising: 

a first module for identifying an execution order of critical events of a program; 

a second module for generating groups of critical events of said program, wherein for 
each group, critical events belonging to said group belong to a common execution thread; and 

a third module for generating, for each execution thread, a logical thread schedule that 
identifies a sequence of said groups so as to aUow deterministicaUy replaying a non-deterministic 
arrival of stream socket connection requests, a non-detenninistic number of bytes received during 
message reads, a non-determmistic binding of stream sockets to local ports, and a non- 
deterministic arrival of datagram messages^, 

wherein said deterministicaUy replaying compris es recording events of a plurality of 
virtual mar -binf.s. each virtual machine being assigned a uni q ue virtual machine identity during a 
record phase .. 

65 . (Currently amended) A software facility system for supporting execution replay with 
respect to a stream socket Application programming interface (API) comprising: 

a first module for identifying an execution order of critical events of a program; 

a second module for generating groups of critical events of said program, wherein for 
each group, critical events belonging to said group belong to a common execution thread; and 
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a third module for deterministically replaying non-deterministic arrival of stream socket 
connection requests, non-deterministic number of bytes received during message reads, and non- 
deterministic binding of stream sockets to local ports, 

wherein said de.termimstir.allv replavin p comprises recording events of a plurality of 
virtual machines, each virtual machine b e ing assigned a unique virtual machine identity during a 
record phase .. 

66. (Currently amended) A software facility system for supporting execution replay with 
respect to datagram socket Application Programming Interface (API) including: 

a first module for identifying an execution order of critical events of a program; 

a second module for generating groups of critical events of said program, wherein for 
each group, critical events belonging to said group belong to a conunon execution thread; 

a third module for determining out-of-order delivery of packets; and 

a fourth module for determining a non-deterministic number of packets delivered during 
different executions of the same program, to support an execution replay with respect to said 
datagram socket Application Programming Interface (API):, 

wherein said execution replav compr ises recor ding events of a plurality of virtual 
machines, each virtual machine being assigned a u niq ue virtual machine identity during a record 
phase .. 

67. (Original) A programmable storage medium tangibly embodying a program of machine- 
readable instructions executable by a digital processing apparatus to perform a method of 
recording and replaying execution of distributed programs on a computer system in a distributed 
environment, said method comprising: 

identifying an execution order of critical events of a program; 

generating groups of critical events of said program, wherein for each groi^, critical 
events belonging to said group belong to a common execution thread; and 

generating, for each execution thread, a logical thread schedule that identifies a sequence 
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of said groups so as to allow determimstically replaying a non-deterministic arrival of stream 
socket comiection requests, a non-deterministic number of bytes received during message reads, 
a non-deterministic binding of stream sockets to local ports, and a non-deterministic arrival of 
datagram messages^ 

,»K^r.in ^^i^ determini stir^llv renlavinP comprises recordiny events of a plurality of 
virtual machines e^nh virtual ma nHin^ being assigned a unique virtual machine identity during a 
record phase .. 

68. (Original) A programmable storage medium tangibly embodying a program of machine- 
readable instructions executable by a digital processing apparatus to perform a method for 
supporting execution replay with respect to a stream socket Application programming interface 
(API), said method comprising: 

identifying an execution order of critical events of a program; 

generating groups of critical events of said program, wherein for each group, critical 
events belonging to said group belong to a common execution thread; and 

deterministically replaying non-deterministic arrival of stream socket connection 
requests, non-deterministic number of bytes received during message reads, and non- 
deterministic binding of stream sockets to local ports^^gnd 

wherein said deterministically reni avin p comprises recording events of a plurality of 
virhial machines, each virtual machine heme a ssipned a unique virtual machine identity during a 
record phase . 

69. (Previously presented) A programmable storage medium tangibly embodying a program 
of machine-readable instructions executable by a digital processing apparatus to perform a 
method for supporting execution replay with respect to datagram socket Application 
Programming Interface (API), said method including: 

identifying an execution order of critical events of a prograim 

generating groups of critical events of said program, wherein for each group, critical 
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events belonging to said group belong to a common execution thread; 
determining out-of-order delivery of packets; and 

determining a non-deterministic number of packets delivered during different executions 
of the same program, for supporting an execution replay with respect to said datagram socket 
Application Programming Interface (API)i 

whftram said execution renlav co m prises recording events of a plurality of virtual 
machines, ea ch virtual machine- being assig n ^^ a unique virtual machine identity duri^ig a recoyd 
phase . 

70. (New) The method according to claim 1 , wherein for point-to-point communication, a 
socket is created, 

wherein a plurality of socket application progranuning interfaces (APIs) are provided 
including socket APIs for listening for connections on a stream socket, binding a socket to a local 
port, and determining the number of bytes that can be read without blocking, and 

wherein each stream socket call is mapped into a native method call in a vutual machine 
implementation. 

7 1 . (New) The method according to claim 1 , wherein in a replay phase, at a corresponding 
read event, a virtual machine reads only numRecorded number of bytes even if more bytes are 
available to read. 
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